大数据上的数据稽查原理和方法介绍（上）
本次内容将分为上下两篇介绍数据稽查的原理与方法。本文涉及其概念、处理流程、相关语法开关的简单介绍。
何为数据稽查
经常参与数据分析的人员知道，在向业务表导入数据时，如果数据清洗做的不彻底，很可能会无意录入脏数据。这些脏数据的存在将影响数据分析和查询结果的精确性。为了提高分析准确度，减少由脏数据带来的误判和对分析过程的干扰，需要依靠数据稽查功能，对业务表中的数据进行排查控守。
以Inceptor为例，它所采用数据稽核方式是，根据规则将脏数据写入用户指定的脏数据表（Log Error Table），在该表中标注每一条脏数据的非法原因，在数据导入完成后，返回总记录数、导入记录数的接口、数据质量报告，以方便监控程序对脏数据进行判断与处理，或者打印出显示报错信息。这些特性都是为了使数据稽查能够在脏数据存在的情况下尽可能的保护系统或保证业务的顺畅执行。
记录哪些脏数据类型
Inceptor开启数据稽查后，系统将对具有如下问题的数据进行报错并记录至Log Error Table：
字符串中含有定界标识符，导致一行数据被误读为多行。试想，若字段值中存在定界标识符，读入记录的字段数将与定义数量相违。对于这种情况，系统将通过判断字段总数是否和定义一致来识别。
以目标表的类型为准，进行类型匹配与类型转换，如果数据源的类型无法转换为目标类型，则被视为脏数据。
在通过UDF结合过滤条件，实现数据转换以及过滤时，对类型不匹配的数据打印报错或记录于Log Error Table。
对不符合NOT NULL限制的记录报错。
数据稽查的处理流程
完整的数据稽查功能按照如下的处理流程实现，建议在使用数据稽查功能以及设置相关配置时，结合该流程决定相关参数值：
在创建一个外表的同时指定Log Error Table（目前Inceptor的数据稽查仅可作用于外表）。
当通过查询语句访问该外表数据时，每解析一行记录，若所得数据为上述四种无效数据之一，就将该行写入Log Error Table。
允许指定REJECT策略，即当错误率达到一定的行数或者比例时，就停止数据读取。
Inceptor数据稽查相关语法
指定Log Error Table
需要在创建外表时为其指定Log Error Table。
CREATE EXTERNAL TABLE table_name (column1 datatype1, column2 datatype2, ...) LOG ERRORS INTO error_table_name [OVERWRITE] [SEGMENT REJECT LIMIT n [ ROWS | Percent ] ] |
error_table_name是Log Error Table的名称，若不存在系统将自动创建。只允许在创建表时指定。注意关键字LOG ERRORS INTO。
若每次错误信息都重写覆盖Log Error Table，需在语法相应位置写“OVERWRITE”，否则忽略。使用Overwrite的好处是能追溯至更久远的信息，但坏处是每次都会在原有记录的基础上增加内容，使该Log Error Table不断扩增。
若需执行REJECT策略，应补充“SEGMENT REJECT LIMIT n…”部分，如果没有需求就忽略。n是REJECT阈值，表示停止读入之前允许的非法数据最大行数或比例。应注意，分布式结构下，由于语句的执行是分配至不同task实现的，此时n是相对于一个task中的数据行数而言的，而并非总数据行数。
没有指定Log Error Table的表也可以受到数据稽查的保护，只是错误信息不会收录于Log Error Table。
指定了Log Error Table并不代表启动了数据稽查，需要通过后面将介绍的开关控制。
例. 创建外表指定关联的Log Error Table
创建employee表，导入employee.txt中的记录。employee.txt的内容如下：
指定employee表的Log Error Table为employee_error_table，允许Overwrite，采用LIMIT=2的Reject策略，即task访问脏数据大于两行时就停止执行。创建语句如下：
CREATE EXTERNAL TABLE employee ( id int NOT NULL, name string, age tinyint, degree string, onboard int ) ROW FORMAT DELIMITED FIELDS TERMINATED BY ',' LOCATION '/DataAudit/employee' LOG ERRORS INTO employee_error_table SEGMENT REJECT LIMIT 2 ROWS; |
以下为“SELECT * FROM employee”的结果：
可以发 48 30898 48 14988 0 0 3631 0 0:00:08 0:00:04 0:00:04 3632这其中有三行记录涉及脏数据：
1行和10行的age字段无法由源数据的字符串类型转为整型，因此显示为NULL。
11行的id字段为空，但是在定义时我们对id做了NOT NULL限制，因此非法。
后面会讲到数据稽查如何对它们做处理。
控制开关
下面是和数据稽查相关的三个开关，用于控制其工作特性：
1. SET inceptor.data.audit = true/false;
数据稽查总开关，开启时会做脏数据和NOT NULL检查，默认关闭。
2. SET inceptor.strict.evaluate = true/false;
是否在遇到脏数据时报Exception，默认关闭。
3. SET inceptor.notnull.audit = true/false;
是否对NOT NULL Constraint进行检查，默认关闭。
上述三个开关之间有如下关系：
inceptor.data.audit设为true后，后面两个开关强制为true，启动inceptor.data.audit之后再对两个子开关进行设置将不起作用。
后两个开关可以在inceptor.data.audit关闭时做设置。区别在于，如果开启inceptor.data.audit，关于脏数据和NOT NULL限制的报错都会写入Log Error Table；若在关闭inceptor.data.audit后启动inceptor.strict.evaluate或inceptor.notnull.audit，检测到的报错将被打印于界面。
例1.开inceptor.data.audit的范例
① 总开关打开后，发现SELECT * FROM employee仅返回了合法数据。此后，查询语句都将只访问合法数据。
② 稽查只考虑当前查询语句所涉及的字段。例如，虽然①返回8条结果，此语句返回age字段中的合法值有9个。这是因为，count(age)只会顾及age字段的合法值，虽然第11行引入了脏数据，但是它的age字段确实是合法的。
③ 总共有三行脏数据录入Log Error Table。
以上行为都符合Inceptor数据稽查的设定。
例 2. 关inceptor.data.audit，开inceptor.strict.evaluate的范例
关闭inceptor.data.audit，开启inceptor.strict.evaluate后，Inceptor将对访问到的脏数据报Exception，并不会记录于Log Error Table。
总结
数据稽查作为脏数据过滤器，它不仅可以保证查询语句仅访问有效干净的数据，而且为修正脏数据提供线索，实现了脏数据和健康数据之间的隔离。因此在保障语句顺利执行，确保分析结果正确性方面具有重要的意义和作用。若能熟练掌握数据稽查的使用和控制方法、用于脏数据修正，定会使数据可靠性的高度更升一级。
下次我们将继续围绕数据稽查，介绍如何修改它的属性，会带来什么影响，以及如何阅读Log Error Table的内容，和它的权限控制方法。
大数据开放实验室由星环信息科技（上海）有限公司运营，专门致力于大数据技术的研究和传播。若转载请在文章开头明显注明“文章来源于微信订阅号——大数据开放实验室”，并保留作者和账号介绍。